System-calls are used by computer user-applications to request services provided by an operating system (OS) kernel. System-call routines generally provide services which user programs usually do not have permission to perform and/or services which access shared resources moderated by the operating system. One field in which system-calls are widely used is computer communications. System-calls are used to create and terminate connections, send and receive messages and transfer status information.
Communications are generally performed by establishing a communication end point, referred to as a socket, which could be viewed as a type of mailbox. A user application manipulates the socket, and transfers data to/from the socket using system-calls.
Because communication functions, such as receiving data, depend on other processes running on the computer, on other hardware units of the computer and/or on remote units, communication system-calls may take a very long time to complete successfully. Various input/output (I/O) modes have been defined for the behavior of user applications while they are waiting for a communication operation to be performed. In a “blocking mode” or “blocking state”, which is generally used by default, the user application waits for the communication operation to complete and does nothing until the system-call returns. In “non-blocking” mode, system-call routines accessing a socket return immediately to the user application, even if the task requested in the system-call was not completed yet.
As mentioned above, the communication operations generally depend on hardware communication devices, which copy received data into memory buffers. After data is placed in a buffer, an interrupt signal is generally sent to the operating system of the computer. The interrupt signal is handled by a driver corresponding to the device. The driver collects data from buffers containing newly arrived data and passes the data to an operating system communication stack, which directs the data to relevant sockets.
After an interrupt is raised by the device, it takes a considerable amount of time until the interrupt is dispatched to the interrupt handler. In addition, interrupts require processing resources for their handling and therefore devices are configured to wait a short amount of time before raising an interrupt, so that a plurality of events can be handled by a single interrupt. This, however, further adds to the latency of receiving data. There have been suggestions of systems which reduce the need for interrupts or avoid them altogether.
U.S. Pat. No. 6,748,460 to Brice Jr. et al., the disclosure of which is incorporated herein by reference, describes a method of handling I/O requests using a hierarchy of vector registers.
U.S. Pat. No. 7,788,391 to Sen et al., the disclosure of which is incorporated herein by reference, describes a system in which interrupts poll one or more devices in addition to performing their task. If the polled devices have pending requests, an interrupt to handle the pending requests is scheduled for handling after the current interrupt is completed.